1. Technical Field
The present disclosure relates generally to information processing systems and, more specifically, to post-reset firmware processing for runtime data.
2. Background Art
Before a computer system can operate, it must have an operating system (OS) in its memory that allows the computer's resources to be reached and controlled by the other software, such as the various application programs. Loading of this operating system is performed during initialization processing, referred to as “boot” or “re-boot” processing, that is performed when a system experiences a power cycle or warm start event.
Traditionally, a computer system includes a basic input/output system (BIOS) memory that stores the code for the boot sequence that the central processing unit (CPU) executes to detect, apply power to, and initialize the computer components. The BIOS performs a power-on self-test (POST) when the system is turned on. This test is used to ensure that the system is functioning properly and to gather information about what the system contains. When a problem is identified with the system during the POST, the BIOS may produce an error message. The message is displayed to the user screen, as a result of the BIOS accessing the video card to print the message. The mechanism that the BIOS uses to print the boot message to the screen is a BIOS interrupt call facility. Specifically, Int 10h is called by the BIOS in order to utilize video services to print error information to the screen.
The Int 10h facility may also sometimes be used by the operating system. For example, the Int 10h video services interrupt facility may be utilized to provide error information to the screen when an OS panic or “screen of death” occurs. Such a panic occurs when the OS detects an internal system error from which it cannot recover. Attempts by the operating system to read an invalid or non-permitted memory address are a common source of kernel panics. A panic may also occur as a result of a hardware failure or a bug in the operating system.
In contrast to the traditional boot method described above, various mechanisms also exist for secure booting. The Unified Extensible Firmware Interface (UEFI) specification defines a model for the interface between operating systems and platform firmware. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together, these provide a standard environment for booting an operating system and running pre-boot applications. More information about UEFI may be found on the public Internet at URL www*uefi*org/home. Please note that periods have been replaced with asterisks in this document to prevent inadvertent hyperlinks. The UEFI standard describes an application programmer interface (API) that allows the operating system to pass data to the firmware. The mechanism for passing information from the OS to the firmware in the UEFI standard may be referred to as a “capsule”. By passing runtime OS panic data to firmware using the capsule mechanism, reliance on the legacy Int 10h facility may be avoided.